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(54) Digital certificate including authorization data 



(57) A structured digital certificate (30) includes a hi- 
erarchy of folders (38-44). Each folder (38-44) contains 
authorization information for a specific relying party, 
such that a single structured digital certificate (30) can 
be used by multiple relying parties. A hash of the digital 
certificate is computed, and each folder contributes the 
hash of its authorization information rather than the au- 



thorization information relevant to the overall hash. The 
structured digital certificate (30) is presentable to a re- 
lying party in a state where only the authorization infor- 
mation relevant to the relying party is visible to the rely- 
ing party, because the authorization information of un- 
related folders are replaced by the hash of the authori- 
zation information. 
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Description 

[0001] This patent application is related to the follow- 
ing Non-Provisional U.S. Patent Applications: Serial 
Number 09/483,185, entitled "AUTHORIZATION IN- 
FRASTRUCTURE BASED ON PUBLIC KEY CRYP- 
TOGRAPHY," Serial Number 09/483,356, entitled 
"LIGHTWEIGHT PUBLIC KEY INFRASTRUCTURE 
EMPLOYING DISPOSABLE CERTIFICATES," and Se- 
rial Number 09/483,1 86, entitled "LIGHTWEIGHT PUB- 
LIC KEY INFRASTRUCTURE EMPLOYING UN- 
SIGNED CERTIFICATES," and the following Provision- 
al U.S. Patent Application Serial Number 60/176,157, 
entitled "PUBLIC KEY VALIDATION SERVICE," which 
were all filed on even date herewith, are all assigned to 
the same assignee as the present application. 
[0002] The present invention relates to verifying an 
entity's identity and/or capabilities on a data network, 
and more particularly, to an apparatus and method for 
using hierarchically structured digital certificates con- 
taining authorization information to verify the identity 
and/or capabilities of an entity on a data network. 
[0003] In everyday life, trust is granted between indi- 
viduals based on characteristics defining the relation- 
ship of the individuals and the identity of the individual 
in question, such as familiarity, occupation, status, and 
third party voucher of the individual in question. Howev- 
er, trust between individuals communicating on a public 
internet is not typically granted in such a simple and 
straightforward manner, because individuals can as- 
sume almost any identity in cyberspace. While the pub- 
lic internet offers flexibility and freedom, the public inter- 
net also instills high levels of distrust, especially when 
granting authority to an individual or when transmitting 
private, sensitive, or confidential information. 
[0004] On the public internet, a digital certificate is 
typically used to verify the identity and/or capabilities of 
a subject or sender of the digital certificate presented to 
a recipient or relying party of the digital certificate. A third 
party, referred to as a certificate authority or issuer of 
the digital certificate, researches the subject/sender de- 
siring certification, and issues a digital certificate to the 
subject/sender to vouch that the subject/sender of the 
message is actually who they say they are. The certifi- 
cate authority digitally signs the digital certificate. The 
subject of the digital certificate presents the signed dig- 
ital certificate to the relying party who trusts the certifi- 
cate authority. The relying party computes a crypto- 
graphic hash of contents of the digital certificate and us- 
es the cryptographic hash together with a certificate au- 
thority's public key, which is readily available, to verify 
the digital signature. The verification of the digital sig- 
nature verifies that the digital certificate was issued by 
the certificate authority. 

[0005] Basic public key digital certificates contain a 
public key and a name associated with the sender. Ex- 
tended public key certificates typically contain additional 
fields of authorization information not found in the basic 



public key certificates. Authorization certificates omit the 
name, and bind the public key directly to authorization 
information. Attribute certificates omit the public key, 
and bind the name to authorization information. 

5 [0006] Currently, the leading digital certificate stand- 
ard is X.509 version 3 (X.509v3). The X.509v3 standard 
is an extended public key certificate standard, which can 
contain additional fields of authorization information not 
found in the basic public key certificates. The X.509v3 

10 standard supports Secure Sockets Layer 3.0 encryption 
along with other encryption schemes. Both Netscape 
Communicator 4.0 and Microsoft's Internet Explorer 4.0 
support X509v3 certificates. 

[0007] In X.509v3 digital certificates, each extension 
15 field has a criticality flag. The criticality flag is employed 
in situations where the recipient of a digital certificate is 
presented with one or more extension fields within the 
digital certificate that the recipient does not understand, 
perhaps because the extension field is newer than the 
20 computer program used by the recipient. If the criticality 
flag is not set, the recipient can ignore the unknown ex- 
tension field. If the criticality flag is set, the relying party 
must reject the digital certificate. 
[0008] In certain situations, it is convenient to collect 
25 information intended for multiple uses in the same digital 
certificate by using two or more unrelated fields within 
the digital certificate. This approach provides the sim- 
plicity of a single digital certificate for a wide variety of 
authentication and authorization needs. This approach, 
30 however, compromises confidentiality since all recipi- 
ents have access to all fields, related or unrelated to the 
recipient's requirements. For example, a single digital 
certificate may grant access to a Unix platform and also 
grant permission to sign purchase orders. In this exam- 
35 pie, the digital certificate has first type fields that specify 
a user ID and group ID for the Unix platform, as well as 
second type fields that specify a limit on the value of 
purchase orders that the recipient of the digital certifi- 
cate is authorized to sign. Thus, when the digital certif- 
40 jcate is used to access the Unix platform, the second 
type fields (i.e., the purchase order limit) are unrelated 
to the recipient's requirements and may become visible 
to the Unix administrator, such as by being recorded on 
the system log. The Unix administrator has no need to 
45 know the limit on the value of purchase orders, and it 
would be best if this purchase order information were 
not disclosed unnecessarily. 

[0009] Alternative approaches have been developed 
to work around the confidentiality problem that results 
50 from two or more unrelated fields residing within the 
same digital certificate. In a first alternative approach, 
confidentiality is achieved by encrypting some or all of 
the fields of the digital certificate. The first alternative 
approach only provides protection against a third party 
55 that eavesdrops on the transmission of the digital certif- 
icate to the relying party. This first alternative approach 
cannot provide confidentiality against the recipient itself, 
because the recipient needs access to the plaintext of 
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the entire digital certificate in order to compute a cryp- 
tographic hash necessary to validate the digital certifi- 
cate. 

[0010] In a second alternative approach, the sender 
uses separate digital certificates instead of placing in- 
formation in multiple, unrelated fields within asingle dig- 
ital certificate. For example, instead of using one digital 
certificate containing the public key and the name of the 
sender together with three types of fields containing au- 
thorization information for three unrelated applications, 
the second alternative approach uses four separate dig- 
ital certificates. The four separate digital certificates in- 
clude afirst basic public key certificate binding the public 
key to the sender name, and three attribute certificates. 
Each attribute certificate binds the sender name to the 
corresponding authorization information contained in 
the field type of the given attribute certificate. This sec- 
ond alternative approach has an advantage in that the 
four digital certificates can be signed by four independ- 
ent certificate authorities. On the other hand, the second 
alternative approach has the disadvantage in that it re- 
quires four digital signatures instead of one, and four 
transactions over a network instead of one when the cer- 
tificate authority issues the digital certificate to the sub- 
ject. Thus, the second approach is more computation- 
ally expensive and results in more network traffic than 
the certificate authority issuing a single digital certificate 
to the subject. 

[0011] The present invention seeks to provide an im- 
proved digital certificate. 

[0012] According to an aspect of the present inven- 
tion, there is provided a structural digital certificate as 
specified in claim 1 . 

[0013] According to another aspect of the present in- 
vention, there is provided a method of providing confi- 
dentiality of authorisation information as specified in 
claim 4. 

[0014] The preferred embodiments can provide an 
improved type of digital certificate and corresponding 
improved methods of employing the digital certificate so 
that when the sender of a digital certificate presents the 
digital certificate to the recipient of the digital certificate 
for a given purpose, only those fields of the digital cer- 
tificate that have to be inspected by the recipient are 
revealed to the recipient. The preferred desired digital 
certificate provides this recipient confidentiality protec- 
tion without the added computational and network traffic 
overhead resulting from issuing digital certificates. 
[0015] According to the preferred embodiment, there 
is provided a structured digital certificate for enabling a 
first recipient of the structured digital certificate to au- 
thorize a sender of the structured digital certificate. The 
structured digital certificate includes a first type field of 
authorization information relevant to the first recipient 
and readable by the first recipient. The structured digital 
certificate includes a first cryptographic folder contain- 
ing a second type field of authorization information rel- 
evant to a second recipient. The second type field of au- 



thorization information is not readable by the first recip- 
ient. 

[0016] In one embodiment, the structured digital cer- 
tificate includes a second cryptographic folder contain- 
5 ing the first type field. In one embodiment, the first type 
field is not contained in a folder. In one embodiment, 
there are multiple first type fields in the structured digital 
certificate. 

[0017] In one embodiment, the structured digital cer- 
10 tificate includes a sender name and a public key asso- 
ciated with the sender. 

[0018] In one embodiment of the present invention, 
the cryptographic folders of authorization information 
are structured fields, containing a plurality of nested 

15 fields. Each of the plurality of nested fields can be a fold- 
er itself. In one embodiment, the digital certificate is an 
X.509v3 digital certificate. The X.509v3 digital certifi- 
cate may include extension fields that describe how the 
certification can be used. The extension fields include 

20 one or more criticality flags. In one embodiment the un- 
related cryptographic folders contain an encrypted hash 
value. 

[0019] The preferred embodiment also provides a 
method of providing confidentiality of authorization in- 
25 formation in a digital certificate shared by multiple recip- 
ients. The method provides cryptographic folders in the 
digital certificate. At least one first type cryptographic 
folder contains at least one first type field of authoriza- 
tion information relevant to a first recipient. At least one 
30 second type cryptographic folder contains at least one 
second type field of authorization information relevant 
to a second recipient. The certificate authority issues the 
digital certificate by signing the digital certificate and 
sending the signed digital certificate to the subject. The 
35 subject then delivers the signed digital certificate to the 
first recipient. The at least one first type field of author- 
ization information is readable by the first recipient. The 
at least one second type field of authorization informa- 
tion is not readable by the first recipient. The first recip- 
40 jent verifies the authenticity of the signed digital certifi- 
cate. 

[0020] According to another aspect of the present in- 
vention, there is provided a method of signing a digital 
certificate at a certificate authority. The method provides 
45 cryptographic folders in the digital certificate having au- 
thorization information. The certificate authority closes 
all of the cryptographic folders in the digital certificate. 
A cryptographic hash of the digital certificate is comput- 
ed with all folders closed. Digital certificate signature is 
50 computed with the computed cryptographic hash of the 
digital certificate and a private key of the certificate au- 
thority. 

[0021] In one embodiment, a given cryptographic 
folder X is closed according to the present invention in 
55 the following manner. All of the nested folders in folder 
X are recursively closed. A cryptographic hash is com- 
puted of the contents of folder X including all recursively 
closed nested folders in folder X. The contents of folder 
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X are replaced with the computed cryptographic hash 
of the contents of folder X. A flag is set in the header of 
folder X to indicate that folder X is closed. 
[0022] According to another aspect of the present in- 
vention, there is provided a method of delivering a digital 
certificate from a subject of the digital certificate to a re- 
cipient of the digital certificate. The method provides 
cryptographic folders in the digital certificate having au- 
thorization information. A digital certificate signature is 
transmitted from a certificate authority to the subject of 
the certificate. An unsigned copy of the digital certificate 
is transmitted from the certificate authority to the subject 
of the certificate. Any folders in the unsigned copy of the 
digital certificate that do not have authorization informa- 
tion relevant to the recipient are closed. The unsigned 
copy of the digital certificate and the digital certificate 
signature are transmitted from the subject of the digital 
certificate to the recipient. 

[0023] In one embodiment of the present invention, 
the step of transmitting a copy of the unsigned digital 
certificate from the certificate authority to the subject of 
the certificate is performed over a secure delivery chan- 
nel. In one embodiment, the secure delivery channel is 
protected via Internet Protocol Security (IPSEC). In an- 
other embodiment, the secure delivery channel is pro- 
tected by Secure Sockets Layer (SSL). 
[0024] According to another aspect of the present in- 
vention, there is provided a method of verifying a signa- 
ture for a digital certificate sent by a subject of the digital 
certificate to a recipient of the digital certificate. The 
method provides cryptographic folders in the digital cer- 
tificate having authorization information. The recipient 
obtains a public key of the certificate authority corre- 
sponding to a private key used by the certificate author- 
ity to sign the digital certificate. The recipient closes any 
of the cryptographic folders left open in the digital cer- 
tificate by the subject of the digital certificate. The recip- 
ient computes a cryptographic hash of the digital certif- 
icate. The recipient authenticates the signature for the 
digital certificate. 

[0025] The structured digital certificate and corre- 
sponding methods of employing the structural digital 
certificate according to the described embodiments of- 
fer several advantages over conventional digital certifi- 
cates. A single structured digital certificate according to 
the present invention can be utilized for multiple, unre- 
lated purposes and still provide recipient confidentiality 
protection without the added computational and network 
traffic overhead resulting from sending multiple digital 
certificates. The hierarchical structure of cryptographic 
folders utilized within the present invention makes it pos- 
sible to disclose only those fields of the structured digital 
certificate that have to be inspected by the recipient for 
a given specific purpose. Since all but one folder of a 
structured digital certificate will typically be closed (i.e., 
contents of the folder replaced with a cryptographic 
hash), when the digital certificate is transmitted from the 
sender to the recipient over a network, the time taken to 



transmit the digital certificate over the network is re- 
duced. 

[0026] An embodiment of the present invention is de- 
scribed below, by way of example only, with reference 
5 to the accompanying drawings, in which: 

Figure 1 is a block diagram of an embodiment of 
structured digital certificate; 
Figure 2 is a flowchart illustrating an embodiment 
of method of providing field confidentiality in digital 
certificates; 

Figure 3A is a flowchart illustrating an embodiment 
of method of signing structured digital certificates at 
a certificate authority; 

Figure 3B is a flow chart illustrating an embodiment 
of method of closing a given cryptographic folder X; 
Figure 4 is a block and data flow diagram illustrating 
how a signature is generated for a structured digital 
certificate at a certificate authority; 
Figure 5 is a flowchart illustrating an embodiment 
of method of delivering a structured digital certifi- 
cate and corresponding encrypted message to a 
message recipient; 

Figure 6 is a block and data flow diagram illustrating 
how a structured digital certificate is delivered to a 
message recipient from a certificate authority, via 
the subject of the certificate; 
Figure 7 is a flowchart illustrating an embodiment 
of method of verifying the authenticity of a signature 
of a structured digital certificate; 
Figure 8 is a block and data flow diagram illustrating 
how an embodiment of message recipient verifies 
the authenticity of a structured digital certificate; 
and 

Figure 9 is a block diagram of a computer system 
and a corresponding computer readable medium in- 
corporating a function for providing field confidenti- 
ality in digital certificates. 

[0027] In the following detailed description of the pre- 
ferred embodiments, reference is made to the accom- 
panying drawings which form a part hereof, and in which 
is shown by way of illustration specific embodiments in 
which the invention may be practiced. It is to be under- 
stood that other embodiments may be utilized and struc- 
tural or logical changes may be made without departing 
from the scope of the claims. The following detailed de- 
scription, therefore, it not to be taken in a limiting sense. 
[0028] Figure 1 is a block diagram of an embodiment 
of structured digital certificate 30. Structured digital cer- 
tificate 30 is a data structure, digitally signed by an is- 
suer (i.e., a certificate authority), that includes authori- 
zation information about another entity, referred to as a 
subject (i.e., a sender). The subject of structured digital 
certificate 30 presents the structured digital certificate 
to third parties who trust the issuer of structured digital 
certificate 30. The third parties are referred to as relying 
parties (i.e., recipients). The relying party computes a 
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cryptographic hash of the structured digital certificate 30 
and uses this hash, together with the public key of the 
issuer, which is readily available, to verify the digital sig- 
nature of structured digital certificate 30. 
[0029] In one embodiment, structured digital certifi- 
cate 30 is a basic public key certificate and includes a 
public key 32 and a sender name 34 associated with the 
subject of structured digital certificate 30. In another em- 
bodiment, structured digital certificate 30 is an extended 
public key certificate and includes, in addition to public 
key 32 and sender name 34, additional fields 36, 37 and/ 
or cryptographic folders 38, 40, 42 and 44 which contain 
authorization information. One example of an extended 
public key certificate is a X.509v3 certificate, previously 
described in the Background of the Invention section of 
the present specification. 

[0030] In one embodiment, structured digital certifi- 
cate 30 includes authorization fields 36 and 37 contain- 
ing authorization information used for multiple, unrelat- 
ed purposes. When structured digital certificate 30 is 
used for one specific purpose, it is desirable to hide the 
information contained in unrelated fields. One example 
structured digital certificate 30 can be used to grant ac- 
cess to a UNIX platform and to also grant permission to 
sign purchase orders. As a result, example structured 
digital certificate 30 has a first type authorization field 
37 that specifies a user ID and a group ID for the UNIX 
platform, as well as a second type authorization field 36 
that specifies a limit on the value of the purchase orders 
that the subject is authorized to sign. When example 
structured digital certificate 30 is used to access the UN- 
IX platform, all authorization fields 36 and 37 of struc- 
tured digital certificate 30 may become visible to the UN- 
IX administrator, such as by being recorded on the sys- 
tem log. However, the UNIX administrator has no need 
to know the limit on the value of purchase orders as con- 
tained in second type authentication field 36. Thus, it is 
desirable to hide the information contained in second 
type authentication field 36 when the UNIX administra- 
tor examines structured digital certificate 30. 
[0031] In one embodiment, an authorization field (or 
fields) is kept confidential by placing the authorization 
field in one of the cryptographic folders 38, 40, 42, and 
44 and replacing the authorization information of the 
cryptographic folder with a cryptographic hash of the au- 
thorization information. This is accomplished without im- 
pairing the ability of the recipient of structured digital cer- 
tificate 30 to verify the digital signature. 
[0032] Cryptographic folders 38, 40, 42 and 44 are 
each a structured field, containing any number of nested 
fields. The nested fields can themselves be crypto- 
graphic folders. In the illustrated example, structured 
digital certificate 30 contains four cryptographic folders 
38, 40, 42, and 44. Cryptographic folder 42 contains two 
additional cryptographic folders 46 and 48 along with 
authorization field 50. Cryptographic folder 48 contains 
one additional cryptographic folder 52 along with author- 
ization field 54. 



[0033] In one embodiment, cryptographic folders 38, 
40, 42, 44, 46, 48, and 52 can be in one of two states, 
open or closed. The current state is indicated by a flag 
in the header of the cryptographic folder. In X.509v3 dig- 
5 ital certificates, each extension (i.e., authorization) field 
has a criticality flag. The criticality flag is employed in 
situations where a recipient (i.e., relying party) is pre- 
sented with one or more extension fields that it does not 
understand, perhaps because the extension is newer 
than the computer program used by the relying party. If 
the criticality flag is not set, the relying party can ignore 
the unknown extension. If the criticality flag is set, the 
relying party rejects structured digital certificate 30. 
[0034] Cryptographic folders provide for increased 
flexibility in the use of criticality flags, but the interaction 
of cryptographic folders and criticality flags must be han- 
dled cautiously. An authorization field is defined recur- 
sively as being visible if it is not inside a cryptographic 
folder or if it is inside an open cryptographic folder which 
is itself visible. An application must reject a digital cer- 
tificate if it contains a visible field where the criticality 
flag is set. 

[0035] The issuer of the structure digital certificate 30 
must ensure that a critical field is not placed inside an 
irrelevant cryptographic folder. Thus, if a critical field is 
relevant to a relying party, then, in the folder hierarchy, 
every cryptographic folder containing the authorization 
field must also be relevant to that relying party. These 
cryptographic folders must be open when the structured 
digital certificate 30 is presented to the relying party, and 
the critical authentication field must be visible. 
[0036] FIG. 2 is a flowchart of a method illustrated 
generally at 100 for providing field confidentiality in 
structured digital certificates, such as the structured dig- 
ital certificate 30 illustrated in FIG. 1 . At block 1 02, meth- 
od 1 00 begins by signing structured digital certificate 30 
at a certificate authority. The certificate authority (i.e., 
issuer) of structured digital certificate 30 closes all cryp- 
tographic folders within the structured digital certificate 
in order to generate a signature for the structured digital 
certificate. The method step indicated at block 102 for 
signing the structured digital certificate 30 is described 
in greater detail in reference to FIG. 3A. 
[0037] After structured digital certificate 30 has been 
signed at block 1 02, the digital certificate signature and 
a copy of the digital certificate with at least one crypto- 
graphic open folder is delivered to the recipient via the 
subject of the digital certificate, as indicated at block 
104. Only authorization information relevant to the re- 
cipient is visible to the recipient within the signed digital 
certificate (i.e., via open folders). The method step indi- 
cated at block 104 for delivering the structured digital 
certificate 30 to the recipient is described in greater de- 
tail in reference to FIG. 5. 

[0038] Upon receipt of the signed structured digital 
certificate 30, the recipient verifies the authenticity of the 
signed digital certificate, as indicated at block 106. Be- 
fore verifying the signed digital certificate, the recipient 
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closes any cryptographic folders that are left open by 
the subject of the digital certificate. Thus, the relying par- 
ty is able to perform the signature verification independ- 
ently of the state of the cryptographic folders in the copy 
of the structured digital certificate presented by the sub- 
ject. The method step indicated at block 1 06 for verifying 
the authenticity of the structured digital certificate 30 is 
described in greater detail in reference to FIG. 7. 
[0039] FIG. 3A is a flowchart illustrating one embodi- 
ment of a method 1 02 for signing structured digital cer- 
tificates 30 at a certificate authority. As stated previous- 
ly, before structured digital certificate 30 is signed or ver- 
ified, any cryptographic folders present within structured 
digital certificate 30 are closed. Method 102 begins by 
closing all of the cryptographic folders in structured dig- 
ital certificate 30, as indicated at block 1 1 0. Next, a cryp- 
tographic hash of the structured digital certificate 30 is 
computed, as indicated at block 112. The cryptographic 
hash can be computed by a variety of methods. In one 
embodiment, the cryptographic hash is computed by 
SHA-1. At block 114, the digital certificate signature is 
computed with the computed cryptographic hash of the 
digital certificate and a private key of the certificate au- 
thority. 

[0040] Fig. 3B is a flow chart illustrating one embod- 
iment of a method 1 1 5 for closing a cryptographic folder 
X. As indicted at block 116, all of the nested folders in 
folder X are recursively closed. As indicated at block 
117, a cryptographic hash is computed of the contents 
of folder X including all recursively closed nested folders 
in folder X. As indicated at block 118, the contents of 
folder X are replaced with the computed cryptographic 
hash of the contents of folder X. As indicated at block 
1 1 9, a flag is set in the header of folder X to indicate that 
folder X is closed. 

[0041] FIG. 4 is a block and data flow diagram illus- 
trating an operation 1 1 8, where a signature is generated 
for structured digital certificate 30 at the certificate au- 
thority. As indicated at block 110 of FIG. 3A, all crypto- 
graphic folders within structured digital certificate 30 
must be closed before a signature can be generated. In 
operation 1 1 8, the authorization information contents of 
open cryptographic folder 52 (i.e., the lowest level cryp- 
tographic folder within the hierarchy of cryptographic 
folders) is replaced with a cryptographic hash value, and 
cryptographic folder 52 is closed, as indicated at 120 in 
FIG. 4. Next, the authorization information contents of 
open cryptographic folders 46 and 48 are replaced with 
corresponding cryptographic hash values, and crypto- 
graphic folders 46 and 48 are closed, as indicated at 
1 22. The authorization information contents of open top- 
level cryptographic folders 38, 40, 42, and 44 within 
structured digital certificate 30 are then replaced with 
corresponding cryptographic hash values, and crypto- 
graphic folders 38, 40, 42 and 44 are closed, as indicat- 
ed at 124. At this point, the hierarchy of cryptographic 
folders within structured digital certificate 30 have been 
"flattened" such that a signature can be generated for 



the structured digital certificate 30, as indicated at 126. 
[0042] FIG. 5 is a flowchart illustrating one embodi- 
ment of a method 104 for delivering structured digital 
certificate 30 to a recipient of the digital certificate. Meth- 

5 od 1 04 begins by transmitting the digital certificate sig- 
nature from the certificate authority (i.e., issuer) to the 
subject of the digital certificate, as indicated at block 
130. At block 132, a copy of the unsigned digital certif- 
icate is transmitted from the certificate authority to the 

10 subject of the digital certificate. The subject of the digital 
certificate then closes any cryptographic folders in the 
copy of the unsigned digital certificate that the recipient 
does not need to see (i.e., folders do not contain author- 
ization information relevant to the message recipient), 

15 as indicated at block 134. Finally the copy of the un- 
signed digital certificate and the digital certificate signa- 
ture generated by the certificate authority are transmit- 
ted from the subject of the digital certificate to the recip- 
ient of the digital certificate, as indicated at block 136. 

20 [0043] FIG. 6 is a block and data flow diagram illus- 
trating an operation 150 where a structured digital cer- 
tificate signed by a certificate authority is delivered to a 
recipient, via the subject of the certificate. As described 
previously, certificate authority 1 52 closes all of the cryp- 

25 tographic folders within structured digital certificate 30 
before signing structured digital certificate 30. After the 
structured digital certificate has been signed, digital cer- 
tificate signature126 is delivered to a subject 154 of the 
digital certificate. In addition to the digital certificate 

30 signaturel26, certificate authority 152 also delivers a 
copy of the structured digital certificate 1 58 where all of 
the cryptographic folders are open to the subject 1 54 of 
the digital certificate. If the copy of the structured digital 
certificate 1 58 contains sensitive information, then it be- 

35 comes necessary to provide security to a delivery chan- 
nel 1 59 between certificate authority 1 52 and the subject 
1 54 of the certificate. In one embodiment, delivery chan- 
nel 159 is secured by Internet Protocol Security 
(IPSEC). In an alternate embodiment, delivery channel 

40 159 is secured by Secure Sockets Layer (SSL). 

[0044] Subject 154 of the digital certificate forwards 
the digital certificate signature 126 to recipient 156. Be- 
fore submitting the copy of the structured digital certifi- 
cate 1 58 to recipient 1 56, subject 1 54 of the digital cer- 

45 tificate closes any cryptographic folders that recipient 
156 does not need to see, as indicated at 160. 
[0045] FIG. 7 is a flowchart illustrating one embodi- 
ment of a method 106 for verifying the authenticity of a 
signature of a structured digital certificate 30. In method 

50 1 06, recipient 1 56 obtains a public key of the certificate 
authority 1 52 corresponding to a private key used by the 
certificate authority to sign the digital certificate, which 
is made readily available by certificate authority 1 52, as 
indicated at block 178. Method 106 closes any crypto- 

55 graphic folders left open in the copy of the structured 
digital certificate by subject 1 54 of the digital certificate, 
as indicated at block 1 80. As indicated at block 1 82, re- 
cipient 1 56 computes a cryptographic hash of the struc- 
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tured digital certificate 158 with all folders closed. As in- 
dicated at block 184, recipient 156 verifies the signature 
for the digital certificate with the public key and the com- 
puted cryptographic hash of the digital certificate. 
[0046] FIG. 8 is a block and data flow diagram illus- 
trating an operation 21 0 where a message recipient ver- 
ifies the authenticity of a structured digital certificate. In 
operation 21 0, recipient 1 56 obtains a public key 21 4 of 
the certificate authority 152, as indicated at 178. Before 
verifying signed digital certificate 126, recipient 156 
closes all cryptographic folders that were left open by 
the subject 154 of the certificate 154 in the copy of the 
digital certificate 160, as indicated at block 180. As in- 
dicated at block 182, recipient 156 computes a crypto- 
graphic hash 216 of the digital certificate 212 having all 
cryptographic folders closed. As indicated at block 1 84, 
recipient 156 verifies the signature of the digital certifi- 
cate 1 26 with the public key 21 4 and the computed cryp- 
tographic hash 216 of the digital certificate. 
[0047] FIG. 9 illustrates one embodiment of a compu- 
ter system 250 and an external computer readable me- 
dium 252 which can be employed to provide field confi- 
dentiality in digital certificates at a certificate authority 
to incorporate a method of signing a digital certificate; 
at a subject of the digital certificate to incorporate a 
method of delivering the digital certificate from the sub- 
ject to a recipient of the digital certificate; or at the re- 
cipient of the digital certificate to incorporate a method 
of verifying a signature for the digital certificate. Embod- 
iments of external computer readable medium 252 in- 
clude, but are not limited to: a CD-ROM, a floppy disk, 
and a disk cartridge. Any one of the above methods for 
providing field confidentiality in digital certificates can be 
implemented in a variety of compiled and interpreted 
computer languages. External computer readable me- 
dium 252 stores source code, object code, executable 
code, shell scripts and/or dynamic link libraries for any 
one of the above methods for providing field confidenti- 
ality in digital certificates. An input device 254 reads ex- 
ternal computer readable medium 252 and provides this 
data to computer system 250. Embodiments of input de- 
vice 254 include but are not limited to: a CD-ROM read- 
er, a floppy disk drive, and a data cartridge reader. 
[0048] Computer system 250 includes a central 
processing unit 256 for executing any one of the above 
methods for providing field confidentiality in digital cer- 
tificates. Computer system 250 also includes local disk 
storage 262 for locally storing any one of the above 
methods for providing field confidentiality in digital cer- 
tificates before, during and after execution. Any one of 
the above methods for providing field confidentiality in 
digital certificates also utilizes memory 260 within the 
computer system during execution. Upon execution of 
any one of the above methods for providing field confi- 
dentiality in digital certificates, output data is produced 
and directed to an output device 258. Embodiments of 
output device 258 include, but are not limited to: a com- 
puter display device, a printer, and/or a disk storage de- 



vice. 

[0049] A method is provided by which the subject (i. 
e., sender) of a digital certificate can keep certain fields 
within the digital certificate confidential as the sender 

5 presents the digital certificate to a relying party (i.e., re- 
cipient). This specific field confidentiality is accom- 
plished through a structured digital certificate which in- 
cludes a hierarchical structure of cryptographic folders. 
In addition to providing field confidentiality, the de- 

10 scribed embodiments can improve the speed of signa- 
ture verification by the receiving party, reduce network 
traffic, and reduce computational overhead. 
[0050] The disclosures in United States patent appli- 
cation no. 09/483,189, from which this application 

15 claims priority, and in the abstract accompanying this 
application are incorporated herein by reference. 



Claims 

20 

1 . A structured digital certificate (30) for enabling a first 
recipient of the structured digital certificate to au- 
thorize a sender of the structured digital certificate, 
the structured digital certificate comprising: 

25 

a first type of authorization (87) relevant to the 
first recipient and readable by the first recipient; 
and 

a first cryptographic folder (38-44) containing a 
30 second type field of authorization information 

(36) relevant to a second recipient and reada- 
ble by the second recipient, wherein the second 
type field of authorization information is not 
readable by the first recipient. 

35 

2. A digital certificate as in claim 1 , comprising one or 
more of: 

a second cryptographic folder (38-44) contain- 
40 ing the first type field; 

multiple type fields (37); 

a sender name; and/or 

a public key associated with the sender. 

45 3. a digital certificate as in claim 1 or 2, wherein the 
first type field (37) is not contained in a cryptograph- 
ic folder (38-44). 

4. A method of providing confidentiality of authoriza- 
50 tion information in a digital certificate shared by mul- 
tiple recipients, the method comprising the steps of: 

providing cryptographic folders (38-44) in the 
digital certificate, wherein at least one first type 
55 cryptographic folder contains at least one sec- 

ond type cryptographic folder (36) contains at 
least one second type field of authorization in- 
formation relevant to a second recipient; 
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issuing and the digital certificate (30) at a cer- 
tificate authority by signing the digital certificate 
and sending the signed digital certificate to a 
subject; 

delivering the signed digital certificate from the 5 
subject to the first recipient, wherein the at least 
one first type field of authorization information 
(37) is readable by the first recipient, and the at 
least one second type field of authorization in- 
formation (36) is not readable by the first recip- 10 
ient; and 

verifying the authenticity of the signed digital 
certificate (30) by the first recipient. 

5. A method as in claim 4, comprising one or more of 15 
the following: 

(a) the step of signing the digital certificate at a 
certificate authority comprises the steps of 
closing all of the cryptographic folders in the 20 
digital certificate computing a cryptographic 
hash of the digital certificate and computing a 
digital certificate signature with computed cryp- 
tographic hash of the digital certificate and a 
private key of the certificate authority; 25 

(b) the step of delivering the signed digital cer- 
tificate to the first recipient includes the steps 
of closing any cryptographic folders in the copy 
of the unsigned digital certificate that do not 
have at least one first type field of authorization 30 
information and transmitting the copy of the un- 
signed digital certificate and the digital certifi- 
cate signature from the subject of the digital 
certificate to the first recipient; and 

(c) the step of verifying the authenticity of the 35 
digital certificate by the first recipient includes 
obtaining a public key from the certificate au- 
thority, closing any cryptographic folders left 
open in the unsigned digital certificate, comput- 
ing a cryptographic hash of the unsigned digital 40 
certificate with all folders closed and verifying 

the signature of the digital certificate with the 
public key and the computed cryptographic 
hash of the unsigned digital certificate. 

45 

6. A method of signing a digital certificate at a certifi- 
cate authority, the method comprising the steps of: 

providing cryptographic folders (38-44) in the 
digital certificate (30) having authorization in- 50 
formation; 

closing all of the cryptographic folders in the 
digital certificate; 

computing a cryptographic hash of the digital 
certificate (30); and 55 
computing a digital certificate signature with the 
computed cryptographic hash of the digital cer- 
tificate and a private key of the certificate au- 



thority. 

7. A method as in claim 6, wherein the step of closing 
all of the cryptographic folders (38-44) in the digital 
certificate (30) includes closing a cryptographic 
folder X according to the following steps: 

recursively closing all nested folders in folder X; 
computing the cryptographic hash of the con- 
tents of folder X; 

replacing the contents of folder X with the com- 
puted cryptographic hash of the contents of 
folder X; and 

setting a flag in a header of folder X to indicate 
that folder X is closed. 

8. A method of delivering a digital certificate from a 
subject of the digital certificate to a recipient of the 
digital certificate, the method comprising the steps 
of: 

providing cryptographic folders (38-44) in the 
digital certificate (30) having authorization in- 
formation; 

transmitting a digital certificate signature from 
a certificate authority to the subject of the cer- 
tificate; 

transmitting an unsigned copy of the digital cer- 
tificate (30) from the certificate authority to the 
subject of the certificate; 
closing any folders (38-44) in the unsigned 
copy of the digital certificate that do not have 
authorization information relevant to the recip- 
ient; and 

transmitting the unsigned copy of the digital 
certificate and the digital certificate signature 
from the subject of the digital certificate to the 
recipient. 

9. A method of verifying a signature for a digital certif- 
icate (30) sent by a subject of the digital certificate 
to a recipient of the digital certificate, the method 
comprising the steps of: 

providing cryptographic folders (38-44) in the 
digital certificate (30) having authorization in- 
formation; 

obtaining a public key of the certificate authority 
corresponding to a private key used by the cer- 
tificate authority to sign the digital certificate 

(30); 

closing any of the cryptographic folders (38-44) 
left open in the digital certificate (30) by the sub- 
ject of the digital certificate; 
computing a cryptographic hash of the digital 
certificate (30) with all cryptographic folders 
closed; and 

verifying the signature for the digital certificate 
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with the public key and the computed crypto- 
graphic hash of the digital certificate. 
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